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(54) Header compression for general packet radio service tunneling protocol (GTP) 



(57) A UMTS (Universal Mobile Telecommunica- 
tions System) core network supports a compression 
framework that provides for header compression of 
General Packet Radio Service Tunneling Protocol 
(GTP)-Encapsulated Packets. In particular, the GTP/ 



UDP(User Datagram Protocol)/IP( Internet Protocol) 
header is compressed. In addition, the UMTS core net- 
work also supports RTP(Real Time Protocol)/UDP/IP 
header compression independent of the GTP/UDP/IP 
header compression. 
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Description 

FIELD OF THE INVENTION 

5 [0001] This invention relates generally to communications and, more particularly, to packet communications systems. 
BACKGROUND OF THE INVENTION 

[0002] As wireless systems continue to evolve, communications between a mobile switching center (MSG) and its 
10 base stations are moving to an Internet Protocol (IP) based transport mechanism. (As used herein, the terni wireless 
systems refers to e.g., CDMA (code division multiple access), GSM (Global System for Mobile Communications), the 
proposed UMTS (Universal Mobile Telecommunications System), etc.) Given the nature of wireless communications, 
e.g.. real-time voice, any IP-based transport needs to utilize a protocol that accommodates real-time applications. 
[0003] One such protocol is the Real Time Protocol (RTP) (e.g., see H. Schulzrinne, R. Frederick, V Jacobson, "RTP: 
15 A Transport Protocol for Real-Time Appiications; RFC 1 889). RTP is attractive since it is an available Internet Engi- 
neering Task Force (IETF) protocol for handling real-time streams, RTP traffic is encapsulated in UDP (user datagram 
protocol), and IP packets. 

[0004] Unfortunately, the use of RIP/UDP/IP generates a large overhead when voice-over-IP applications are run 
over wireless networks since the voice payload is usually small (e.g. 10 to 20 bytes) while the RTP/UDP/IP header is 
20 40 bytes. 

SUMMARY OF THE INVENTION 

[0005] Besides the large overhead associated with RTP/UDP/IP headers, this situation is further aggravated by the 
25 use of General Packet Radio Service Tunneling Protocol (GTP)- Encapsulated Packets. In this case, the GTP/UDP/IP 
overhead is about 980% with a voice payload of 1 0 bytes. Therefore, and in accordance with the invention, the GTP/ 
U DP/IP header is compressed for transmission. 

[0006] In an embodiment of the invention, a UMTS core network supports a compression framework that provides 
for compression of a GTP/UDP/IP header (referred to herein as "GTP header compression" or a "compressed GTP 
30 header"). In addition, the UMTS core network also supports RTP/UDP/IP header compression (refen^ed to herein as 
"RTP header compression" or a "compressed RTP header^') independent of the GTP header compression. As a result, 
the UMTS core network is able to more efficiently transport small multimedia RTP packets. 

BRIEF DESCRIPTION OF THE DRAWING 

35 

[0007] 

FIG. 1 shows a prior art uncompressed GTP encapsulated RTP packet; 

FIG. 2 shows a UMTS network embodying the principles of the invention; 
40 FlGs. 3 and 4 show illustrative protocol stacks for use in a mobile station; 

FIG. 5 shows illustrative compressor/decompressor locations in the UMTS network of FIG. 2; 

FIGs. 6 - 10 show Illustrative message flows 

FlGs. 11 - 13 show prior art IP, UDP and RTP header fomriats; 

FIG. 14 shows an illustrative format for a compressed FTTP header; 
45 FIG. 16 shows an illustrative format for a compressed GTP header; and 

FIG. 1 6 shows an illustrative high-level block diagram of a packet server for use in perfonning GTP header com- 
pression in accordance with the principles of the invention.. 

DETAILED DESCRIPTION 

50 

[0008] An illustrative format of an uncompressed GTP encapsulated RTP packet 1 0, as known in the art (release 97 
version), is shown in FIG. 1 . The GTP/UDP/IP header 11 comprises an IP/UDP header 12 and a GTP header 13. The 
GTP/UDP/IP header 11 sits on top of GTP payload 14 as known in the art. With a voice payload illustratively equal to 
1 0 bytes (e.g., payload 1 5 of FIG. 1 ), this results in an overhead of about 980% as a result of the GTP/UDP/IP header 
55 11 . Therefore, and in accordance with the invention, the GTP/UDP/IP header is compressed for transmission. It can 
be observed from FIG. 1 that GTP payload 14 also transports an IP header and a UDP header. As known in the art, 
IP/UDP header 12 comprises origination and destination infomnation with respect to the tunnel, while the IP header 
and UDP header of GTP payload 14 comprises origination and destination information with respect to the communi- 
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cations endpoints. (It should be noted that the TID value is based upon the release 97 version as defined in Global 
System for Mobile Communications (GSM) 04.08 document, Digital cellular telecommunications system (Phase 2+); 
mobile radio interface layer 3 - specification. The TID value includes 8 bytes: 12 bits MCC, 8 bits MNC, 40 bits MSIN 
and 4 bits NSAP1. The MCC, MNC, MSIN and NSAPI are parts of the IMSI defined in the GSM 04.08 document.) 

5 [0009] An illustrative UMTS networl< 200 modified in accordance with the principles of the invention is shown in FIG. 
2. Other than the inventive concept, the elements shown in FIG. 2 are well l<nown and will not be described in detail. 
For example, UMTS network 200 comprises a radio access network (RAN), a core network (CN), a backbone network, 
and an illustrative endpoint represented by IP End Host 240. The backbone network comprises the Internet and the 
publicswitched telephone network (PSTN). The RAN comprises mobile station (MS) 205, node B 21 0 and radio network 

10 controller 215. (Although UMTS uses the ternn "node B," this is also referred to as a base station.) The CN comprises 
a serving GPRS support node (SGSN) 220, gateway GPRS support node (GGSN) 225 and element 230, which com- 
prises a gatekeeper (GK) (a component in ITU H.323) and an IP/PSTN gateway (GW) (for translation between H.323 
and the PSTN). Although shown as single block elements, the elements of UMTS network 200 include stored-program- 
control processors, memory, and appropriate interface cards (not shown). For the purposes of this description, an 

15 illustrative end-to-end connection is between MS 205 and IP End Host 240 (which are also referred to as endpoints). 
The term "packet server" as used herein refers to any packet processor, illustrations of which are the above-mentioned 
elements of UMTS 200. 

[0010] In accordance with the invention, UMTS network 200 supports a compression framework that provides for 
GTP header compression. In addition, UMTS network 200 also supports RTP header compression independent of the 

20 GTP header compression. (As used herein the temns "GTP header compression" or "compressed GTP header" refer 
to compression of a GTP/UDP/I P header. Similarly, the temns "RTP header compression" or "compressed RTP header" 
refer to compression of an RTP/UDP/IP header.) Since GTP header compression is independent from RTP header 
compression, the GTP peers can be different from the RTP peers (but this is not required). This also provides some 
design flexibility since some multimedia traffic may not use RTP but purely UDP encapsulation. As a result, UMTS 

25 network 200 is able to more efficiently transport small multimedia packets. The description of the inventive concept 
continues below. 

Overview of Header Compression 

30 [0011] It should be understood that, in accordance with the invention, RTP header compression and GTP header 
compression can be negotiated independently between peers (described further below). Other than the inventive con- 
cept, compression/decompression techniques are well-known and will not be described herein. For example, typically 
a compressor/decompressor is a software module stored in a memory (not shown), e.g., of MS 205, and executed by 
a stored-program-controlled microprocessor (not shown), e.g.. of MS 205. The software module uses conventional 

35 programming techniques, which, as such, will also not be described herein, to store shared infomiation (described 
below) and format for transmission compressed, or reduced, fomis of a GTP/UDP/IP header or an RTP/UDP/IP header 
(described below). 

[0012] With respect to the mobile station, e.g. MS 205 of FIG. 2, two illustrative protocol stacks comprising a com- 
pressor/decompressor are shown in FIGs. 3 and 4. In the protocol stack of FIG, 3, the RTP compressor/decompressor 

40 is located between the IP layer and the RLC/MAC (radio link control/media access control) link layer. (For simplicity, 
the physical layer of the protocol stack Is not shown.) In the protocol stack of FIG. 4, the RTP compressor/decompressor 
is located between the application layer and the RLC/MAC link layer. (Again, the physical layer is not shown.) (Although 
a form of RTP header compression is described below, It should be noted that the embodiment of FIG. 4 also represents 
that fonn of RTP header compression in which an RTP header is simply stripped off in its entirety (an RTP header is 

45 illustrated in FIG. 13).) 

[0013] In a complementary fashion, a corresponding RTP compressor/decompressor and GTP compressor/decom- 
pressor are located in the UMTS network. An illustrative view of the location of the RTP compressor/decompressor 
and the GTP compressor/decompressor in UMTS network 200 is shown in FIG. 5. In FIG. 5, the RTP compressor/ 
decompressor (C/D) is located in MS 205 and IP end host 240 (i.e., MS 205 and IP end host 240 are RTP peers), while 
50 the GTP compressor/decompressor (C/D) is located in RNC 215 and GGSN 225 (I.e., RNC 215 and GGSN 225 are 
GTP peers). 

[0014] RTP is a point-to-point protocol. As such, for RTP header compression peers, it should be noted that this 
assumes that a link layer identifier (ID) is mapped to each RTP session identifier One illustrative RTP session identifier 
comprises the IP destination address and the IP destination port number (these are of the endpoints), the SSRC 
55 identifier (e.g., see FIG. 13). and the UDP destination port (e.g., see FIG. 12). If ATM (asynchronous transfer mode) 
is used as transport, an illustrative link layer ID is the associated VPI/VCI (Virtual Path Identifier/Virtual Connection 
Identifier). The mapping of the link layer ID and the RTTP session occurs within each RTP peer. 
[0015] It should also be noted that an RTP compressor/decompressor can alternatively be put in the radio access 
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network, e.g., in RNC 215, or even in the core network, e.g., at SGSN 220. 

[0016] Within the core network, it is preferable (though not required) to put the GTP compressor/decompressor in 
GGSN 225. If the GTP compressor/decompressor is located in SGSN 220, handovers ( also known in the art as "hand- 
offs") due to SRNS (Serving Radio Network Subsystem) relocation may still have to be accounted for. (As known in 
5 UI\^TS, an SRNS includes not only a particular RAN but also supporting elements, e.g., a data base (not shown).) 
However, with the GTP compressor/decompressor located at GGSN 225, no context transfer Is required even for the 
case of SRNS relocation. 

[0017] Turning now to FIGs. 6-10, illustrative message flows for using GTP header compression and RTP header 
compression In UMTS network 200 are shown. Other than the inventive concept, the description that follows utilizes 

10 well-known UMTS message flows, which are not described herein. In FIGs. 6 - 10 it Is assumed that the GTP header 
peers are RNC 215 and GGSN 225, while the RTP header peers are MS 205 and IP End Host 240. 
[0018] FIG. 6 illustrates how a mobile station, e.g., MS 205 of FIGs. 2 and 5, negotiates GTP header compression/ 
decompression. After the "Attach Procedures" are performed between MS 205 and RNC 215 (as known in the art), 
MS 205 transmits to SGSN 220 an "Activate PDP (packet data protocol) context" request message modified, in ac- 

15 cordance with the invention, to include a GTP header compression request represented by a predefined identifier 
designated as "GTP_Comp." In response, SGSN 220 sends a "Create PDP context" request message (modified to 
include the "GTP_Comp" identifier) to GGSN 225 to signify a request for GTP header compression. GGSN 225 re- 
sponds with a "Create PDP context" response message as an acknowledgment (modified to Include the "GTP_Comp" 
identifier). Upon receipt of the "Create PDP context" response message, SGSN 220 sends an "Activate PDP context" 

20 response message (modified to include the "GTP_Comp" Identifier) to MS 206. 

[0019] As noted above, in orderto establish a GTP header compression context, either a GTP_Compressed flag (e. 
g., a predefined bit pattem) or a GTP Header Compression Context Information Element (IE) is added to the existing 
message set. This GTP Header Compression_Context IE will comprise the GTP full header infomiation . If this element 
is present, one need not send a full GTP header to establish the GTP header context. Otherwise, one may need to 

25 send one or more packets with full GTP header to establish GTP header context. (It should be noted that for the case 
where the GTP compressor/decompressor Is located at an SGSN, and an SRNS relocation occurs resulting in a change 
of SGSN, the new SGSN can send a GTP context enquiry message to the old SGSN and the old SGSN can reply with 
the appropriate GTP context response message so that the new SGSN can now be the new compressor/decompressor 
point for GTP header compression.) 

30 [0020] Turning now to FIG. 7, illustrative packet flows are shown. For GTP header compression, at least one packet 
with a full GTP header is sent to establish the GTP compressed header context (FIG. 7, (A)) between the GTP peers 
(here, represented by RNC 215 and GGSN 225). As noted, packets are communicated using GTP between GGSN 
225 and RNC 21 5 (i.e., GTP temninates at GGSN 225 and RNC 215). Once the GTP header compression is negotiated, 
each GTP peer, e.g., GGSN 225 formats data packets in accordance with GTP and then compresses the GTP header 

35 before transmitting the packets (described below) to its GTP peer, here RNC 21 5, which uncompresses the GTP header 
and recovers the payload (which may or may not include RTP) for transmission to MS 205. Similarly, in the other 
direction, RNC 215 compresses the GTP header for transmission to GGSN 225, which uncompresses the GTP header 
and recovers the payload. Packets are communicated between GGSN 225 and I P End Host 240 with a link layer header 
as known In the art. Subsequent to GTP header compression negotiation, RTP header compression may optionally 

40 be negotiated between MS 205 and IP End Host 240 (FIG. 7, (B)) in a similar fashion as that shown for the GTP header 
compression negotiation of FIG. 6. 

[0021] Illustrative RTP header compression context message exchanges are shown in FIG. 8. (Again, modification 
of existing signaling messages are assumed. As such predefined bit values are added to existing message sets to 
identify the additional message requirements, e.g., that this is an "RTP context set up" message.) Initially, two RTP 

45 peers exchange signaling messages to set up the RTP header compression context. An "RTP context set up" request 
message is sent from one RTP peer, e.g., MS 205, to the other RTP peer, e.g., IP End Host 240. An "RTP context Set 
up" response message completes the handshake. Whenever there is a change in the RTP context, the appropriate 
context update code is used in the first byte of the compressed RTP header (described below) to indicate the additional 
changed (or delta) infomnation carried within the RTP compressed header. Thus, an "RTP context update" request 

50 message is an implicit message in the RTP compressed header. However, an "RTP context update" response message 
is optional. (It should be noted that the RTP header compression between the two RTP peers (here represented by 
MS 205 and IP End Host 240) can exchange out-of-band signaling messages to turn on the FTTP header compression. 
Again, since the GTP header compression and the RTP header compression are independent of each other, it is not 
necessary for RTP header compression to be negotiated (in which case, the packets comprise a compressed GTP 

55 header and an uncompressed RTP payload.) Similarly, it is not necessary for GTP header compression to be negotiated 
notwithstanding the use of RTP header compression. 

[0022] Returning to FIG. 7, once the RTP header compression context is set up, subsequent packets are sent using 
GTP header compression and RTP header compression (FIG. 7, (C)) (as noted, assuming both GTP header compres- 
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sion and RTP header compression are turned on). In the event RTP context re-synchronization is required, the receiving 
RTP peer can send a "RTP context repair" message to the sending RTP peer. This is iilustrated in FIG. 9, (D), where 
the receiving RTP peer is represented by IP End Host 240 and the sending RTP peer is represented by MS 205. The 
sending RTP peer then sends one or more RTP packets with full header (FIG. 9 (E)) followed by compressed RTP 
5 packets (FIG. 9 (F)). 

[0023] Simiiarly, when GTP packets are iost, the receiving GTP peer can send a "GTP context repair" message to 
the sending GTP peer. This is illustrated in FIG. 10, (G), where the receiving GTP peer Is represented by GGSN 225 
and the sending GTP peer is represented by RNC 21 5. The sending GTP peer then sends one or more packets with 
a full GTP header (FIG. 1 0, (H)) followed by packets with compressed GTP headers (FIG. 1 0, (I)). (It should be observed 

10 that in this example, RTP header compression synchronization was not lost.) 

[0024] The above-described context repair mechanism for either GTP header compression or RTP header compres- 
sion is performed whenever there are missing packets. It should be noted that one can set a predefined time interval 
threshold beyond which an explicit context repair message is sent to the sender to re-synchronize. 
[0025] Whenever either GTP peer wishes to tear down the GTP context, they can send a GTP context tear down 

15 message (not shown). Similarly, the RTP peers can tear down the RTP context via the transmission of an RTP context 
tear down message (not shown). 

RTP Header Compression 

20 [0026] Although not directly applicable to a UMTS environment, there are existing proposals to reduce the 40-byte 
RTP/UDP/IP header to 4 - 5 bytes (e.g., see S. Casner and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low- 
Speed Serial Links," IETF RFC2508; and L. Jonsson and M. Degemiark and H. Hannu and K. Svanbro, "Robust 
Checksum-based Header Compression", IETF internet draft, Oct 1999). As such, while FIGs. 11 - 13 show prior art 
IP, RTP and UDP header formats for reference purposes, the details of such are not described herein. 

25 [0027] Generally, with respect to an IP header (assuming use of IPv4, the IP version in use today), only the total 
length, packet ID (identification) and header checksum fields will normally change. However, the total length is redun- 
dant since the length is also provided by the link layer. The packet ID usually increments by one or a small number for 
each packet. If it was assumed that there was no IP packet fragmentation, this also would not need to be communicated. 
However, in order to maintain lossless compression, changes in the packet ID may be transmitted. 

30 [0026] With respect to a UDP header, the length field is redundant since the IP total length field and the length are 
indicated by the link layer. The UDP check-sum field will be a constant zero if the source elects not to generate UDP 
checksums. Otherwise, 1 have observed that the UDP checksum must be communicated intact in order to preserve 
the lossless compression. 

[0029] With respect to an RTP header, the SSRC (synchronization source) identifier is constant in a given context 
35 since that is part of what identifies the particular context. For most packets, only the sequence number and the times- 
tamp will change from packet to packet. If packets are not lost or mlsordered upstream from the compressor, the 
sequence number will increment by one for each packet. For audio packets of constant duration, the timestamp will 
increment by the number of sample periods conveyed in each packet. For video, the timestamp will change on the first 
packet of each frame, but then stay constant for any additional packets in the frame. If each video frame occupies only 
40 one packet, but the video frames are generated at a constant rate, then again the change in the timestamp from frame 
to frame is constant. It should be noted that in each of these cases the second-order difference of the sequence number 
and timestamp fields is zero, so the next packet header can be constructed from the previous packet header by adding 
the first-order differences for these fields that are stored in the session context along with the previous uncompressed 
header. When the second-order difference is not zero, the magnitude of the change is usually much smaller than the 
45 full number of bits in the field, so the size can be reduced by encoding the new first-order difference and transmitting 
it rather than the absolute value. 

[0030] The M bit is set on the first packet of an audio talkspurt and the last packet of a video frame. If it were treated 
as a constant field such that each change required sending the full RTP header, this would reduce the efficiency of 
header compression significantly. Therefore, as described further below, an RTP compressed header will carry the M 
50 bit explicitly. 

[0031] If the packets are flowing through an RTP mixer, most commonly for audio, then the CSRC list and CC count 
will also change. However, the CSRC list will typically remain constant during a talkspurt or longer, so it need be sent 
only when it changes. 

[0032] An illustrative fomriat for a compressed RTP header is shown in FIG. 14 for use as part of the RTP header 
55 compression protocol. As noted above, it is assumed an RTP peer transmits the compressed RTP header and maintains 
a collection of shared information (e.g., stored in a memory (not shown) in a consistent state between the compressor 
and decompressor). The compressed RTP header comprises the following fields: 
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a Context Update Code (one byte); 

- an M field (one bit) for the RTP M bit; 
a tinne clicks fleid (seven bits); 

a UDP checksum field (two bytes); 
5 - an IP packet ID (two bytes); 

a CSRC list (two bytes); and 

an ITTP header extension (two bytes). 

[0033] The value of the Context Update Code field indicates what infonnation is included in the ITTP compressed 
10 header as shown in FIG. 1 4. The minimal length for the RTP compressed header is 2 bytes. The RTP timestamps are 
replaced by a timeclick number (1 byte). If the UDP checksum, IPv4 Packet ID, CSRC list and RTP header extension 
need to be included, the compressed RTP header will be longer as shown in FIG. 14. However, most of the time, the 
compressed RTP header will only be 2 bytes (the context update code byte and the M + timeclick byte). 
[0034] With respect to the shared information stored in each RTP peer, there is a separate session context for each 
15 IP/UDP/RTP packet stream, as defined by a particular combination of the IP source and destination addresses, UDP 
source and destination ports, and the RTP SSRC field (described earlier). The number of maintained session contexts 
may be negotiated between the compressor and decompressor. Once can map each RTP context to a GTP TID (GTP 
tunnel ID) (the maximum number that can be negotiated is 65536). Each RTP header compression context has its own 
separate sequence number space so that a single packet loss need only invalidate one context. 
20 [0035] The shared infonnation in each RTP header compression context comprises the following Items: 

- the full IP, UDP and RTP headers, possibly including a CSRC list, for the last packet sent by the compressor or 
reconstmcted by the decompressor; and 

the first-order difference for the IPv4 ID field, initialized to 1 whenever an uncompressed IP header for this context 
25 is received and updated each time a delta IPv4 ID field is received in a compressed packet. 

[0036] As mentioned above, and shown in FIG. 14, there is a timeclicks field in the compressed RTP header which 
replaces the RTP timestamps field of an RTP header (e.g., see FIG. 1 3). As such, a mechanism is required o compute, 
or recover, the timestamp value and sequence number in an RTP receiving peer from the timeclicks field value. As 
30 such, the following definitions are made: 



sd: sample duration (in ms); 
TS^fff timestamp number for the previous packet; 
^^nevr timestamp number for this packet; 
35 ^Tf,f^^ wall clock reading for the previous packet (a wall clock is simply a network reference clock); 

WT^^ wall clock reading for this packet; 

TN^ timeclick number of previous packet in compressed header; 
TA/^j^ timeclick number of this packet in compressed header; 
SN^i^ RTP sequence number of previous packet; 
40 Sf^new- sequence number of this packet; 

T: time period represented using n bits (a cycle period), in units of sample duration, T=2" samples (7 ^ 2"(sd) 

milliseconds (ms)); and 

M: the value of M bit in compressed header. 

45 [0037] The following equations are used to compute, or recover, the timestamp value and sequence number in an 
RTP receiving peer from the timeclicks field value: 



TSne. = TSoid + /; if M = 0 and - /; and (1) 

= TSoi^ + (Scycie * T + 5uck) otherwise; (2) 



SN^^ = SN^^ + 5,^^, if 5«,, != 1 , and d,^^, < T/4 and M 1= 1 ; (3) 

where 
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10 



15 



20 



25 



30 



40 



50 



55 



5^^^ = ( r + TN^^y^ - TN^,J)modT; (where modi is a modulo T operation); (4) 

^'cyde = L ( ^new " M^owJ^J' {where \ J" represent the 'floor) (6) 

S cycle = Scyeu ' ly if <Srtick < 4ck, and Ac* " &f/c/r ^ 772; (7) 
= ^» if <5Udc < <5utick, and &.ic* - 5.c* ^T/2; and (8) 

= otherwise. (9) 

[0036] During a talkspurt, the tinneclicks field value will Increase by one sample. During a silent period, the timeclicl<s 
field will increase by the idle period (expressed in terms of the number of samples). 

[0039] For the timestamp field, the major problem to solve is what to do for the case when the 7-blt timeclick number 
wraps around. During a silent period, if there is no packet sent by the compressor, the time elapse for the silent period 
must be detected (in terms of how many clock cycles has passed). Illustratively, a wall clock as known In the art is 
used to overcome this problem (as shown above, e.g., IVT^jyand M/T^^). This separate wall clock at the decompressor 
(or receiving RTP peer) is used to count the cycles. This wall-clock runs at a coarse granularity, e.g. it only increases 
by 1 for every T/4 period where Tis the time period of a cycle represented using 7 bits. 

[0040] With respect to the RTP sequence number field, if sequencing Is required, a compressed header with se- 
quence number should be included every r/4samples and atthe beginning of every talkspurt. A context repair message 
can be sent to request a full RTP header if necessary. If the timeclick value exceeds T/4, and there are lost packets, 
the RTP sequence number can't be updated appropriately until the RTP receiver gets a packet with sequence number 
information. 

[0041] An illustration of how this update algorithm works to provide timestamp and sequence number recovery is 
shown below. It is assumed that 1 8 packets are transmitted from, e.g., MS 205, with consecutive sequence numbers 
1 to 18. Atthe RTP receiver, e.g., IP End Host 240, only packet 18 is received (i.e., packets 7 to 17 are lost). 
[0042] In the first example, its is assumed that the wall clock value is 3 (meaning 3(T/4)) when packet with sequence 
number 6 is received and that TS^^^^ 1 10. When packet 1 8 is received, the wall clock value is 6. The timeclicks value 
at receipt of packets 6 and 1 8 are 11 0 and 75, respectively Using the equations above, the following calculations result, 

TS^^=110; 
5^^= (128 + 75- 110)motfr= 93; 
SivteAf = (6r/4) - 3(T/4))mocfr= 3( T/4) = 96; 
Kycie = L (6f774; - 3(T/4)m = 0; 
5cycie = 0: 

and 

rs^^^= 110 + 93 = 203 
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[0043] In the following second exannple, it is assumed that TS^/tf = 38 and that the wall clock value for packet 6 is 5, 
while the wall clock value for packet 1 8 is 9. The tinneclicks value at receipt of packets 6 and 1 8 are 38 and 32, respec- 
tively. 



TS,y = 38; 



StfcAf = {""^S + 32 - 38)modT= 122; 

10 

^wtfck= (9(T/4) - 5(V/4)) modT= 0; 



15 



5 Wl (9(T/4J - 5(T/4))/rj = 1; 



20 and 

75^^=38+122=160. 

25 [0044] In the following third example, it is assumed that TS^ = 57 and that the wall clock value for packet 6 is 6, 
while the wall clock value for packet 1 8 is 9. The timeclkiks value at receipt of packets 6 and 1 8 are 57 and 28, respec- 
tively. 

"^Sow = 57; 

30 " 

SffcK = (1 28 + 28 - 57) rnodT^ 29; 
5^^^= (9(T/4) - 6CT/4))modr = 3( T/4) = 96; 

^'cycie=L (^(J/^) ' 6(T/4))/rj = 0; 

40 

^cycte = : 

and 

rS„_ = 57+ 122 = 214. 
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GTP Header Compression 



50 



[0045] FIG. 1 5 shows an illustrative forniat for a compressed GTP header. The compressed GTP header comprises 
a version field (Vers, 3 bits), a payload type field (PT, 1 bit), an extension bit field (E, 1 bit), a sequence number field 
(S, 1 bit), a tunnel identifier (TID) present field (T, 1 bit), an SNDCP present field (N, 1 bit), a message type field (Msg 
Type, 1 byte), a two byte length field, a two to four byte tunnel identifier (TID) field, a two byte sequence number field. 
55 a four bit extension code filed, a four bit extension length field, and an extension content field. 

[0046] With respect to the TID field, the most significant bit is used to indicate the size of the TID field. If the value 
of the most significant bit is 0, then the T!D field size is 2-bytes. If the value of this bit is one, then the TID field size is 
four bytes. In addition, the TID field is present only if the value of the T bit field is SET, i.e., equal to a binary one. The 
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E-bit field is used to indicate if an extension header exists. Each extension header comprises a 4 bit extension header 
type (Ext. Type) field, a 4 bit extension header length (Ext. length) field, and an extension content (Ext. Content) field 
(the size of which is indicated by the value of the extension header length field). The value of the extension header 
length field is expressed in temns of multiples of 2 bytes. For example, If a UDP checksum needs to be present, an 
5 appropriate extension header type is defined for this and the extension header length Is 1 (meaning the size of the 
extension content field is 2 bytes since a UDP checksum is 2 bytes long). 

[0047] Since the extension header type field is four bits wide, 16 types of extensions can be defined. Since the 
extension header length field is four bits wide, the extension content field has a maximum size of 32 bytes (i.e., 1 6 two 
byte multiples). It should be noted that if more extension types need to be allocated, the size of these fields can be 
10 adjusted, e.g., to a size of one byte each. 

[0048] The shared infomnation In each GTP header compression context (I.e., stored at each GTP peer) comprises 
the following items (these items are initialized based on the values received in the initial "full" GTP header): 

- the full IP and UDP headers (also, should a UDP checksum be required, the receiving GTP peer simply re-calcu- 
15 lates it based upon the received UDP data); 

the two byte flow label and the LLC Frame number; and 
the TID value. 

[0049] As noted above, the GTP header compression fomnat shown in FIG. 15 supports either two or four byte 
20 optional TID values. (As noted above, the 97 release version of a TID Is 8 bytes. However, TID values may be redefined 
in the future to comprise fewer bytes (hencethe option of having either TID values of two or four bytes in the compressed 
GTP header). The TID field in the GTP header compression fomnat of FIG. 15 is optionally used (via the value of the 
T bit) for updating TID infomnation. 

[0050] Turning briefly to FIG. 16, a high-level block diagram of a representative packet serverfor use in accordance 
25 with the principles of the Invention Is shown. Packet server 606 is a stored-program-control based processor architec- 
ture and includes processor 650, memory 660 (for storing program instructions and data, e.g., for communicating In 
accordance with the above-mentioned GTP header compression, etc.) and communications interface(s) 665 for cou- 
pling to one or more packet communication facilities as represented by path 666. 

[0051] The foregoing merely illustrates the principles of the invention and it will thus be appreciated that those skilled 
30 In the art will be able to devise numerous alternative arrangements which, although not explicitly described herein, 
embody the principles of the Invention and are within its scope. For example, although Illustrated in the context of 
UMTS, the inventive concept is applicable to any wireless system (e.g., UMTS, etc.) or application that requires use 
of a tunneling protocol. 

35 

Claims 

1 . A method for use in a packet server, the method comprising the steps of: 

40 negotiating compression of a GTP/UDP/IP header of a Genera! Packet Radio Service based Tunneling Pro- 

tocol (GTP) with a GTP peer, the GTPAJDP/IP header comprising GTP, User Datagram Protocol (UDP), and 
Internet Protocol (IP) header infonnation; 

initially transmitting the GTP/UDP/IP header to the GTP peer; and 

subsequently transmitting a compressed version of the GTP/UDP/IP header to the GTP peer. 

45 

2. The method of claim 1 wherein the compressed GTP/UDP/IP header comprises at least a tunnel identifier field 
that is less than or equal to four bytes in length. 

3. The method of claim 1 wherein the compressed GTP/UDP/IP header comprises at least, an extension bit field, 
50 which indicates whether an extension field is present or not, a tunnel identifier present field, which indicates whether 

a tunnel identifier field Is present or not. 

4. The method of claim 1 further comprising the steps of: 

55 formatting data packets in accordance a Real Time Protocol (RTP) also having UDP and IP header infomnation; 

and 

compressing the RTP/UDP/IP header before transmitting the packets wherein one field of the compressed 
RTP/UDP/IP header defines whether a UDP checksum field is present or not. 
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